home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group96a.txt / 000011_icon-group-sender _Mon Jan 8 18:07:03 1996.msg < prev    next >
Internet Message Format  |  1996-09-05  |  7KB
  1. Received: by cheltenham.cs.arizona.edu; Tue, 9 Jan 1996 08:52:09 MST
  2. To: icon-group@cs.arizona.edu
  3. Date: 8 Jan 1996 18:07:03 -0700
  4. From: whm@primenet.com (William H. Mitchell)
  5. Message-Id: <4csf3n$744@nnrp1.news.primenet.com>
  6. Organization: Primenet Services for the Internet
  7. Sender: icon-group-request@cs.arizona.edu
  8. References: <199601051418.AA21353@gateway.fedex.com>, <4cm6lc$eob@csnews.cs.colorado.edu>
  9. Subject: Re: RFD: Programming Language Feature Matrix
  10. Errors-To: icon-group-errors@cs.arizona.edu
  11. Status: O
  12.  
  13. Tom Christiansen <tchrist@mox.perl.com> wrote:
  14.  
  15. >Having seen mistaken allegations in this thread against both java and
  16. >perl, such as in portability and security, amongst other things, I propose
  17. >the various factions on the net cooperate to create a feature matrix that
  18. >we can all fill out about many different languages to help for simplistic
  19. >at-a-glance comparisons.  These already exist for shells, newsreaders, and
  20. >web browsers, so it seems a useful thing to have.
  21.  
  22. I think this would be an interesting exercise and if done well, could be
  23. useful.  There's certainly potential for abuse in the composition of the
  24. matrix, but Tom's proposed matrix doesn't look too bad. 
  25.  
  26. Let's see some more attempts at filling it out.  Tom: Do it for perl!
  27.  
  28. I have a few questions and comments on the list, which are flagged with "whm>".
  29. I've elided the items that I didn't have any issue with.
  30.  
  31. data types
  32.     recursive data types
  33.  
  34.         whm> Does this mean that type X can refer directly or indirectly to
  35.              other instances of type X?  Or, does it mean that an object can
  36.          reference itself, such as a list whose first element is itself?
  37.     
  38.     full lexical closures
  39.  
  40.         whm> What's this?
  41.  
  42. function calling conventions
  43.     whm> In this category I suggest adding:
  44.             provision for default value for omitted parameters
  45.         named specification of parameters (vs. only positional)
  46.  
  47. memory allocation
  48.     require explicit allocation/deallocation
  49.     permit explicit allocation/deallocation
  50.     can trash memory via bad pointer/array reference
  51.     reference-based garbage collection
  52.     mark-sweep style garbage collection
  53.     thread-based shared memory 
  54.     process-based shared memory
  55.  
  56.     whm> Hmm... This is a tough one.
  57.  
  58.         I think the fundamental question is whether memory management
  59.         is manual or automatic (garbage collected).
  60.  
  61.         "permit explicit (de)allocation" seems troublesome -- if a language
  62.     can interface with the C library it can explicitly manage some memory.
  63.     If you say the language must have native support for allocation, it
  64.     would eliminate C, which delegates allocation to the library.
  65.  
  66.         I'd say the type of garbage collection is more related to a
  67.         particular implementation than the language itself.
  68.  
  69.         I'd say any language that can interface with a C function can get
  70.     trash memory.
  71.  
  72.         For shared memory, what level of interaction is imagined?  There's
  73.     a spectrum from flipping a bit to arbitrary sharing of data between
  74.     two processes.
  75.  
  76. low-level access
  77.     native machine language access
  78.     
  79.         whm> What do you mean by this?
  80.     
  81.     multi-threaded applications (emulated, native, and/or pthreads)
  82.  
  83.         whm> With this and the questions above re shared memory in mind, maybe
  84.          a section on support for concurrency should be added
  85.  
  86. objects
  87.     fragile superclass problem
  88.     
  89.         whm> What's this?  (I sense a perjorative wording...)
  90.  
  91.     operator overloading
  92.     function overloading
  93.  
  94.         whm> These are more related to data abstraction.  Perhaps that should
  95.          should be a category in itself.
  96.     
  97.     whm> I'd surely say add encapsulation control, and class methods and
  98.          data.  But, if you look at the some of the latest trends in OO
  99.      languages I think you'd find a quite a few things to add here.
  100.  
  101. graphics
  102.  
  103.     whm> I suggest adding platforms on which graphic capabilities are present,
  104.          e.g., X, Windows, Mac, PM, etc.
  105.  
  106. patterns
  107.     file wildcards (*.*)
  108.     ed-style regular expression
  109.     egrep-style regular expressions
  110.     posix-compliant regular expressions
  111.     regular expression extensions/improvements
  112.  
  113.     whm> There's a world beyond regular expressions.  Maybe the classification
  114.          should be what level of language in Chomsky's hierarchy can be
  115.      described with the pattern facilities of the language.  
  116.  
  117. devel tools
  118.  
  119.     introspection (can examine its own state)
  120.  
  121.         whm> There are a lot of levels of introspective capability.  Perhaps
  122.          this should be more specific.
  123.  
  124. easy ramp-up for programmer of...
  125.  
  126.     whm> Hmm... Another tough one.  Maybe a statement of suggested background
  127.          would be better.
  128.  
  129. target application areas
  130.  
  131.     whm> I think that by the time the application areas stop coming in you're
  132.          going to have a pretty big list.  As an alternative, something I
  133.      often think about is the philosophy of a language.  For example,
  134.      I think of C as a language that's close to the machine with few
  135.      limitations on the programmer.  With this could be included the styles
  136.      supported by the language, e.g., imperative, functional, oo, logic,
  137.      etc.
  138.  
  139. size
  140.     compiler size
  141.     complete bundled kit size
  142.     program source size
  143.     program object size
  144.     program memory size
  145.  
  146.         whm> These are all implementation dependent.  Try completing this
  147.          category for ML!
  148.  
  149. robustness and support
  150.  
  151.     formal bug tracking system
  152.  
  153.         whm> Maybe I'm interpreting this wrong but wouldn't be dependent on
  154.          vendors/suppliers?
  155.          
  156.     guaranteed virus-free kits
  157.  
  158.         whm> What do you mean by this?
  159.  
  160. portability
  161.     compiles w/ traditional C
  162.     compiles w/ ansi C
  163.  
  164.         whm> What if there were a language not implemented in C? :-)  Seriously
  165.          though, this question leads into implementation dependencies.
  166.          Maybe it would be appropriate to ennumerate the languages used
  167.          for various implementations.
  168.  
  169. To me, a thorny issue is that of language vs.  library.  Via a library, C
  170. has graphics, regular expressions, shared memory, threads, etc.  If you say
  171. that the language must have native support for an element, say windows or
  172. regular expressions as a first-class data type, then that's biased against
  173. languages like C and Smalltalk that have a small nucleus but have extensive
  174. libraries available. 
  175.  
  176. I'd like to see a category for the preprocessor, if any.  Ada generics and C++
  177. templates are clearly important features, but I see no place for them.  I think
  178. there should be a category on expression evaluation.  That would be a place to
  179. put backtracking and another topic there could be well-defined order of
  180. evaluation.
  181.  
  182.  
  183.